It's weird that you say both she had no material power and also seem to imply the valuation drop and lawsuits were due to her ineptitude?
Anyway she volunteered to be a puppet for a man who is clearly off the rails and her legacy will forever be stained.
I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following:
- The API returns JSON
- CRUD actions are mapped to POST/GET/PUT/DELETE
- The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec
- There's a decent chance listing endpoints were changed to POST to support complex filters
Like Agile, CI or DevOps you can insist on the original definition or submit to the semantic diffusion and use the terms as they are commonly understood.
It's so, so , so hard to walk the line between persistence (which leads to glory) and stubbornness (which leads to more time following already wasted time.)
Congratulations for walking this line correctly.
I agree that some sort of market validation is necessary to at least pretend you are on the former not the latter. Those early usage spikes are helpful reminders that there is a business here somewhere.
I'll also make a note that you spent time on marketing from the early days. Writing blog posts, promoting said posts, having a Discord server, committing to answer emails, all of this is marketing and its likely lead to success more than the code.
I notice whenever there was a dip in revenue, marketing (in the form of more blog posts) was the response. I suspect that was intentional, and definitely a better approach than "let me go away and silently code more features."
So there are valuable lessons to others here. Congratulations not just on the current success but also on sharing the path that leads to success. Ultimately you can show the way, but you can't make people learn from it.
Oh, and I like the bootstrapping approach. I did the same, and I'm not sorry. It's longer and harder but also skips an enormous amount of extra work.
Can this ever work? I understand what you're trying to do here, but this is a lot like trying to sanitize user-provided Javascript before passing it to a trusted eval(). That approach has never, ever worked.
It seems weird that your MCP would be the security boundary here. To me, the problem seems pretty clear: in a realistic agent setup doing automated queries against a production database (or a database with production data in it), there should be one LLM context that is reading tickets, and another LLM context that can drive MCP SQL calls, and then agent code in between those contexts to enforce invariants.
I get that you can't do that with Cursor; Cursor has just one context. But that's why pointing Cursor at an MCP hooked up to a production database is an insane thing to do.
If you’re one of today’s lucky 10,000 and haven’t heard the original 500-mile email story, you can read it at https://web.mit.edu/jemorris/humor/500-miles.
(discussed previously on HN 5 years ago – https://news.ycombinator.com/item?id=23775404 – and 10 years ago – https://news.ycombinator.com/item?id=9338708)
The Alien, Terminator, and Matrix franchises have similar problems.
Aliens successfully changed genres, from horror to action. But subsequent movies could never recapture the primal horror of the original or the fun action of the second. It's almost like there are only two local optima in the Alien movie universe and Alien + Aliens took them both.
Terminator is the same. The first movie was a perfect sci-fi action movie, with a trippy premise and loads of fun. The second was a subversion of the first: the Terminator is the good guy! And that worked too. But after that, where else can you go?
And, of course, they never even bothered to make sequels to The Matrix.
I have trouble explaining to my parents how my job is a real thing. I can only imagine trying to explain ‘I study shapes, but only ones that don’t jut inwards’.
> Sometimes it comes up with a better approach than I had thought of.
IMO this has always been the killer use case for AI—from Google Maps to Grammarly.
I discovered Grammarly at the very last phase of writing my book. I accepted maybe 1/3 of its suggestions, which is pretty damn good considering my book had already been edited by me dozens of times AND professionally copy-edited.
But if I'd have accepted all of Grammarly's changes, the book would have been much worse. Grammarly is great for sniffing out extra words and passive voice. But it doesn't get writing for humorous effect, context, deliberate repetition, etc.
The problem is executives want to completely remove humans from the loop, which almost universally leads to disastrous results.
I've found this to be one of the most useful ways to use (at least) GPT-4 for programming. Instead of telling it how an API works, I make it guess, maybe starting with some example code to which a feature needs to be added. Sometimes it comes up with a better approach than I had thought of. Then I change the API so that its code works.
Conversely, I sometimes present it with some existing code and ask it what it does. If it gets it wrong, that's a good sign my API is confusing, and how.
These are ways to harness what neural networks are best at: not providing accurate information but making shit up that is highly plausible, "hallucination". Creativity, not logic.
(The best thing about this is that I don't have to spend my time carefully tracking down the bugs GPT-4 has cunningly concealed in its code, which often takes longer than just writing the code the usual way.)
There are multiple ways that an interface can be bad, and being unintuitive is the only one that this will fix. It could also be inherently inefficient or unreliable, for example, or lack composability. The AI won't help with those. But it can make sure your API is guessable and understandable, and that's very valuable.
Unfortunately, this only works with APIs that aren't already super popular.
A good chance to bring up something I've been flagging to colleagues for a while now: with LLM agents we are very quickly going to become even more CPU bottlenecked on testing performance than today, and every team I know of today was bottlenecked on CI speed even before LLMs. There's no point having an agent that can write code 100x faster than a human if every change takes an hour to test.
Maybe I've just got unlucky in the past, but in most projects I worked on a lot of developer time was wasted on waiting for PRs to go green. Many runs end up bottlenecked on I/O or availability of workers, and so changes can sit in queues for hours, or they flake out and everything has to start again.
As they get better coding agents are going to be assigned simple tickets that they turn into green PRs, with the model reacting to test failures and fixing them as they go. This will make the CI bottleneck even worse.
It feels like there's a lot of low hanging fruit in most project's testing setups, but for some reason I've seen nearly no progress here for years. It feels like we kinda collectively got used to the idea that CI services are slow and expensive, then stopped trying to improve things. If anything CI got a lot slower over time as people tried to make builds fully hermetic (so no inter-run caching), and move them from on-prem dedicated hardware to expensive cloud VMs with slow IO, which haven't got much faster over time.
Mercury is crazy fast and in a few quick tests I did, created good and correct code. How will we make test execution keep up with it?
When I first read this a question jumped out at me: Wait, Neanderthals were able to render fat? That requires boiling, and doesn't boiling require pottery?
This led me down a bit of a rabbit-hole. It turns out that no, you don't need pottery to boil things, because you can do it just fine in combustible materials like animal hide or birch bark... so long as you keep the water level consistently high enough, because then the container material will never get hotter than 100 degrees Celcius! So that's kind of obvious once you think about it, but what's interesting about this is that nobody ever considered it until just recently and the whole of paleo-anthropology "knew" that humans couldn't boil things until the invention of pottery![1] To me this is a particularly interesting and surprising example of how, in scientific disciplines, bad assumptions can stick around unquestioned even though from the perspective of physics it's quite obvious that they're bad assumptions.
Edit: add reference to some experimental verification[2].
[1] https://paleoanthro.org/media/journal/content/PA20150054.pdf
[2] https://link.springer.com/article/10.1007/s12520-023-01843-z
On the contrary, anthropomorphism IMO is the main problem with narratives around LLMs - people are genuinely talking about them thinking and reasoning when they are doing nothing of that sort (actively encouraged by the companies selling them) and it is completely distorting discussions on their use and perceptions of their utility.
I have the technical knowledge to know how LLMs work, but I still find it pointless to not anthropomorphize, at least to an extent.
The language of "generator that stochastically produces the next word" is just not very useful when you're talking about, e.g., an LLM that is answering complex world modeling questions or generating a creative story. It's at the wrong level of abstraction, just as if you were discussing an UI events API and you were talking about zeros and ones, or voltages in transistors. Technically fine but totally useless to reach any conclusion about the high-level system.
We need a higher abstraction level to talk about higher level phenomena in LLMs as well, and the problem is that we have no idea what happens internally at those higher abstraction levels. So, considering that LLMs somehow imitate humans (at least in terms of output), anthropomorphization is the best abstraction we have, hence people naturally resort to it when discussing what LLMs can do.
> - if you give people the chance to place a label on themselves to give a name/form to a problem, they’ll take it.
This one is widespread among the young people I’ve worked with recently. It’s remarkable how I can identify the current TikTok self diagnosis trends without ever watching TikTok.
There’s a widespread belief that once you put a label on a problem, other people are not allowed to criticize you for it. Many young people lean into this and label everything as a defensive tactic.
A while ago, one of the trends was “time blindness”. People who were chronically late, missed meetings, or failed to manage their time would see TikToks about “time blindness” as if it was a medical condition, and self-diagnose as having that.
It was bizarre to suddenly have people missing scheduled events and then casually informing me that they had time blindness, as if that made it okay. Once they had a label for a condition, they felt like they had a license to escape accountability.
The most frustrating part was that the people who self-diagnosed as having “time blindness” universally got worse at being on time. Once they had transformed the personal problem into a labeled condition, they didn’t feel as obligated to do anything about it.
Decades ago in my first abnormal psych course, the prof warned us that there was an almost iron-clad law that students will immediately start self diagnosing themselves with “weak” versions of every disorder we learn about. In my years since then, it has absolutely held true and now is supercharged by a whole industry of TikTok self-diagnoses.
But there are a few things we can learn from this:
- if you give people the chance to place a label on themselves that makes them feel unique, they’ll take it.
- if you give people the chance to place a label on themselves to give a name/form to a problem, they’ll take it.
- most mental disorders are an issue of degree and not something qualitatively different from a typical experience. People should use this to gain greater empathy for those who struggle.
I'm not going to dive into the specifics of my thoughts on this question. I think a lot of comments here address this.
But does anyone else get embarrassed of their career choice when you read things like this?
I've loved software since I was a kid, but as I get older, and my friends' careers develop in private equity, medicine, law, {basically anything else}, I can tell a distinct difference between their field and mine. Like, there's no way a grown adult in another field evaluates another grown adult in the equivalent mechanism of what we see here. I know this as a fact.
I just saw a comment last week of a guy who proudly serves millions of webpages off a CSV-powered database, citing only reasons that were also covered by literally any other database.
It just doesn't feel like this is right.
According to Indian regulators, every trading day Jane Street would:
1) buy large volumes of stocks and/or stock futures that are part of an index tracking India’s banking sector, early in the day,
2) subsequently place large options trades, betting that the index would decline or volatility would spike later in the day, and
3) later in the day, cash out of the large long positions, dragging the index lower, making far more money on the options trades than on the long positions.
Jane Street can and likely will claim the firm was only arbitraging away pricing inefficiencies, nothing more, nothing less. It was just business as usual, etc., etc.
However, given the scale of the operation, Jane Street's actions sure look like textbook market manipulation. Calling it like I see it.
This isn't for introverts its intended for people with social anxiety, they're different things. Introverts don't necessarily dislike networking they just need recharge time afterwards.
At any rate it doesn't address the core concept. Anyone with anxiety (raises hand) will tell you that the worse thing you can do is care MORE about the thing you're anxious about, yet you've prescribed a bunch of rituals for someone to perform so that they do "well".
The best way to network well is to stop giving a shit about doing it well.
Only tangentially related, and a seemingly lost old-man battle: stop hiding my scrollbar.
Interesting article. Some points I didn't quite agree entirely with. There's a cost and practically limitation to some things (like a physical knob in a car for zooming in and out on a map - although that was probably just an example of intuitive use).
I just recently switched a toggle on a newly installed app that did the opposite of what it was labelled - I thought the label represented the current state, but it represented the state it would switch to if toggled. It became obvious once changed, but that seems the least helpful execution.
Why was the title of this post changed long after posting to something that doesn't match the article title? This editorializing goes directly against HN Guidelines (but was presumably done by the HN team?)
I was there.
My first pay stub had Verant on it, I joined shortly before the SOE transition.
One thing maybe not well known outside of the company was that the MMO subscription revenue enabled a hotbed of experimentation. There was an MMO RTS which never shipped, and several other takes on “can we make genre X an MMO?” that I can’t remember. And then SWG, obviously.
EQ2 had all kinds of interesting people on it as a result - Ken Perlin did the lip sync work (driving facial animations from dialog), Brian Hook worked on the rendered for a while. I’m sure there were others.
Then there’s all the things we didn’t do. I read the complete Harry Potter series specifically because we were in talks with JK Rowling to do a HP MMO, but negotiations failed.
Crazy times.
[addendum] Several of the people in the article are no longer with us (Brad McQuaid, and Kelly Flock at least)
The office park that SOE was located in on Terman Court was also demolished years ago. I remember standing at the door to my office on my last day, looking out the window at the eucalyptus trees and thinking I was never going to see the place again.
I was right.
> With over 90% of the PC market running on NVIDIA tech, they’re the clear winner of the GPU race. The losers are every single one of us.
I have been rocking AMD GPU ever since the drivers were upstreamed into the linux kernel. No regrets.
I have also realized that there is a lot out there in the world besides video games, and getting all in a huff about it isn’t worth my time or energy. But consumer gotta consoooooom and then cry and outrage when they are exploited instead of just walking away and doing something else.
Same with magic the gathering, the game went to shit and so many people got outraged and in a big huff but they still spend thousands on the hobby. I just stopped playing mtg.
I've been following this for a while now.
Kent is in the wrong. Having a lead position in development I would kick Kent of the team.
One thing is to challenge things. What Kent is doing is something completely different. It is obvious he introduced a feature, not only a Bugfix.
If the rules are set in a way that rc1+ gets only Bugfixes, then this is absolutely clear what happens with the feature. Tolerating this once or twice is ok, but Kent is doing this all the time, testing Linus.
Linus is absolutely in the right to kick this out and it's Kent's fault if he does so.
This article is not a "I want to leave tech" article. It is an "I want to have more ownership of the nature of my work" article.
Practically every recommendation is also a tech job, its just not "big tech" where you have very little real decision making power.
Tech itself is not the issue here - tech being filled with high paying jobs where you effectively work on issues that directly damage humanity is the issue. And after you have a high paying job its hard to justify leaving it, and every other similarly paying job is basically the same thing in a different package.
"Fair enough. Since this was our first OSS project, we didn’t realize at first. We’ve now revised it. Thanks for your contribution."
We didn't notice that we copied your codebase, changed the name then pretended to have built it in four days?
Good grief.
> You might be asking: why did you rewrite tmux in Rust? And yeah, I don’t really have a good reason. It’s a hobby project. Like gardening, but with more segfaults.
I love this attitude. We don’t necessarily need a reason to build new things. Who knows what will come out of a hobby project. Thanks to the author for the great write up!
Also, my gardening is full of segfaults, coding a new project is definitely safer to my yard.
My most recent example of this is mentoring young, ambitious, but inexperienced interns.
Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before:
- During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "good catch, I'll fix that" (also reminiscent of an LLM).
- The time spent on trivial issues went down a lot, almost zero, the remaining issues were much more subtle and time-consuming to find and describe.
- Many bugs were of a new kind (to me), the code would look like it does the right thing but actually not work at all, or just be much more broken than code with that level of "polish" would normally be. This breakdown of pattern-matching compared to "organic" code made the overhead much higher. Spending decades reviewing code and answering Stack Overflow questions often makes it possible to pinpoint not just a bug but how the author got there in the first place and how to help them avoid similar things in the future.
- A simple, but bad (inefficient, wrong, illegal, ugly, ...) solution is a nice thing to discuss, but the LLM-assisted junior dev often cooks up something much more complex, which can be bad in many ways at once. The culture of slowly growing a PR from a little bit broken, thinking about design and other considerations, until its high quality and ready for a final review doesn't work the same way.
- Instead of fixing the things in the original PR, I'd often get a completely different approach as the response to my first review. Again, often broken in new and subtle ways.
This lead to a kind of effort inversion, where senior devs spent much more time on these PRs than the junior authors themselves. The junior dev would feel (I assume) much more productive and competent, but the response to their work would eventually lack most of the usual enthusiasm or encouragement from senior devs.
How do people work with these issues? One thing that worked well for me initially was to always require a lot of (passing) tests but eventually these tests would suffer from many of the same problems